home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_1599 / 1274 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  1.8 KB
  1. Subject: Re: sending signals from xdd's 
  2. Date: Tue, 19 Apr 1994 17:02:45 -0700
  3. From: Howard Chu <howard@harry.lloyd.com>
  4.  
  5.  
  6.   This is very analogous to a serial driver, which must send a SIGHUP signal to
  7.   the process group controlled by this device.
  8.   
  9.   > Currently the only possibility I see to do the 1st is to fork a
  10.   > new process (much like minixfs and modm0dev do) that is used to
  11.   > send signals.
  12.   
  13.   It seems mandatory, indeed: if no process does I/O on the socket, the
  14.   device driver functions will never be called, so you can't rely on these
  15.   functions to post signals. Signals should be posted asynchronously, by
  16.   another thread.
  17.   
  18.   > Is there another way (without a different process) to signal
  19.   > different processes from a device driver?
  20.   > 
  21.   > Perhaps (as Juergen suggested some time ago) post_sig() should be
  22.   > made available for device drivers through struct kerinfo?
  23.   
  24.   While it would be a Good Thing, it would not solve the problem indicated
  25.   before, i.e. you still need another thread. But it would have the great
  26.   advantage of allowing this thread to execute in kernel mode, so
  27.   addroottimeout() would be usable...
  28.   
  29. Instead of requiring another thread, you could just install your own handler
  30. in the vbl queue. Or perhaps we can add a queue internal to MiNT that's
  31. processed at regular intervals. In either case you need to be able to call
  32. post_sig in order for it to be useful. My patch to make Fselect work on the
  33. standard BIOS serial ports just checks each port's buffers during vbl
  34. processing and then calls wakeup or wakeselect as required. I suppose I could
  35. also have implemented SIGIO there at the same time...
  36.  
  37. I guess a standard queue would be nice, have every driver that uses it set up
  38. 2 flags (e.g. read_ready and write_ready) that cause appropriate wakeup calls
  39. to be made. We could even implement the Exceptional conditions for select.
  40.